I think that the FreeRTOS task is more hassle than it's worth, and will make this harder to maintain and debug in the long run. I think using a more traditional loop/polling approach is easier to understand and won't require the FreeRTOS dependency, global variable, nor specialized OTA setup.
The drawback is that the I2C read takes a while, ~23ms from my testing, which will slow down the loop() by that much every ~0.25s. Considering this hardware is specialized, I think that is ok.

I'm not sure I understand why you say that it's more hassle than it's worth. It's already implemented and it's working as intended.

The main problem I was trying to alleviate with the task is missing readings. Using loop() or update() has no guarantee with the execution time. I was able to see this first hand when testing yesterday when loop() function of the emporia_vue component was not running fast enough when putting the logger option to VERY_VERBOSE, missing multiple sensor readings. That means that the other components could slow the main sensor loop enough that we would be missing power readings.

Right now, I'm only writing a single sensor reading to the queue, but my goal is to eventually add a way to handle a slow loop() and average all the sensor readings in the queue before publishing them, allowing total_daily_energy to still have a very accurate reading.

Do you have a config where it's missing readings? I didn't realize that was a concern, I'm glad to test it out too (I have my Vue set up with 18 CT clamp and daily energy sensors, which I'm thinking is close to the most stress the loop() will have)

I think nesting this sensor as a sub-object under the clamps config will help with future compatibility. We don't currently give a way to use the current sensor data, which I think we will eventually want to support. Nesting this sensor would help ensure we don't need to make a breaking change when we do add that data.